Hi @daniel347x.

Thank you for your interest in contributing to Loguru.

Getting back at your comment at #173 (comment), it still seems natural to define a limit to the maximum length of the values displayed in the traceback. Since any arbitrary object can end up being printed, this avoids flooding if a long text or verbose dictionary happens to be logged.
Displaying values is convenient for a quick overview in the event of an error during development, but it cannot replace the use of a debugger.

I agree it seems quite straightforward to simply add a new length argument to logger.add(). However, I'm not necessarily in favor of such an approach, as the add() API is already quite complex and I'd like to avoid adding too many new options.

This is why for more advanced cases like yours, it's still possible to fully adapt exception formatting using a custom format function, as demonstrated in the above mentioned ticket.
Given that this is not an very common use case, it seems to be an acceptable solution, which doesn't require any changes to Loguru.

That being said, I understand it can frustrating not to be able to easily adjust the width limit.

Your point makes me realize that it might be interesting to deprecate existing backtrace and diagnose arguments in favor of a new argument dedicated to exception formatting (and which could also deal with max length). This is all the more relevant as there are other formatter (such as the rich one) that could benefit from easier interfacing with Loguru logger. It was actually already suggested in #86.

Rough idea:

logger.add(sys.stderr, format="{time} {message}", traceback=lambda exc: logger.traceback(exc, width=999))

Nothing concrete yet. But I think there's merit in considering a more generic approach, rather than a new length argument.

If it's acceptable to you in the short term, however, I'd be happy to support a new environment variable to set the maximum length of the current traceback. I'd prefer something like LOGURU_TRACEBACK_WIDTH. What do you think?